The invention is related to the art of programmable devices and more specifically to the art of programming programmable devices in-system. The invention will be described in reference to devices that are compliant with “IEEE Standard 1149.1-1990, IEEE Standard Test Access Port and Boundary Scan Architecture”, published by the Institute of Electrical and Electronics Engineers and incorporated herein by reference in its entirety. However, those of ordinary skill in the art will understand that the invention can be applied wherever devices can be programmed over a serial chain.
Many devices, such as, for example, complex programmable logic devices CPLDs, microprocessors, micro-controllers, coprocessors, programmable controllers, sequencers, graphics controllers, memories such as DRAMS, SRAMS, EPROMS, serial EPROMS, flash memories, programmable logic devices (PLDs), and field programmable gate arrays (FPGAs) can be programmed in-system via associated JTAG (Joint Test Action Group) ports (see IEEE Standard 1149.1-1990). Many of these devices are based on non-volatile technologies and therefore, need only be programmed or configured once. According to the IEEE Standard 1149.1-1990, multiple devices can be chained through these ports so that a plurality of devices on a JTAG chain can be accessed for programming and validation. This protocol facilitates in-system programming.
In-system programming of devices is preferable to pre-programming of such devices, before they are installed into a system, because of the apparent disadvantages of pre-programming. For example, pre-programming involves more handling steps. Each extra handling step increases the risk of damaging a device, due to, for example, electro-static discharge (ESD), pins bending, and pin breakage. Pre-programming equipment represents increased capital expenditure. Where similar devices are programmed in different ways, pre-programming requires extra steps or procedures to ensure that only devices programmed appropriately are installed in associated locations in the target system. Of course, extra manufacturing steps require extra manpower and, therefore, additional manufacturing costs.
In-system programming eliminates these disadvantages and has additional advantages. At initial power-up, at the end of a target system manufacturing process in a system designed for self in-system programming, an on-board processor can run a JTAG query and determine that associated programmable devices on a JTAG boundary scan chain are blank. The detection of blank devices triggers an automatic programming procedure. Since the devices are already installed in the system and since the programming procedure programs the devices according to their location in the system, it is guaranteed that a device in a given location is programmed or configured with the appropriate information for that location.
One advantage of this procedure is that the devices need only be handled once, to install them in the system. This is in contrast to procedures that rely on pre-programming, wherein devices must be installed in a programming device, removed from the programming device and then installed in very specific locations in the system based on the programming the devices received.
Another advantage of in-system programmability is that devices can be easily reprogrammed even after they are sold and installed out in the field. For example, as will be described in greater detail below, by updating the contents of a non-volatile memory including programming or configuring information used by the programming procedure, the devices can be automatically updated without the need for extra programming equipment and without returning the system to the factory.
Referring to FIG. 1, currently available systems 110 and related techniques for self-programming in-system devices in target systems 112 include using a development tool to generate an industry standard, high level file referred to as a JEDEC file 114. The JEDEC file 114 contains information about how a device is to be programmed or configured. In the case of, for example, CPLDs, a Serial Vector Format (SVF) file 118 is generated from the JEDEC file using a conversion utility. For example, the device manufacturer (e.g. Xilinx) provides a utility called “jtagprog” 122. The SVF file 118 defines how a JTAG TAP controller of a processor 126 is to be manipulated and what data is to be transferred to a device during programming. The SVF file 118 is substantially ASCII text. The SVF file format is useful where in-system programming is done with and external device temporarily connected to a target system 112. In in-system self-programming environments, the information contained in the SVF files would have to be included in the target system 112. However, the ASCII text format of SVF files is not very efficient and would require too many target system resources (e.g. memory or storage space). Therefore, it has become common to compress SVF files to a format called Xilinx Serial Vector Format (XSVF) 130 using another utility. For example, one manufacturer provides a utility called “svf2xsvf” 134 to perform this transformation. XSVF files are in a compressed binary format, which can be more easily stored in target system hardware. Before storage into an EPROM, for example, the XSVF files 130 may be converted into yet another format, such as, for example, Intel Hex. Each device 140 to be programmed in and by the target system 112 must have its own associated XSVF file 130. Therefore, the required storage space can still be prohibitive.
With currently available self programming, in-system technology, a target system processor 126, such as a microprocessor or a micro-controller, then uncompresses or decodes the XSVF file and executes equivalent routines to those of the temporarily connected SVF based external device.
In-system programming or configuration can be triggered by an external demand or could be triggered by some internal event such as hardware power-up and initialization. In order to ensure that devices are programmed correctly, they are often re-programmed at every power-up. This can create a problematic delay in device operation and devices are reprogrammed even when reprogramming is not required. Alternatively, a verification type SVF file can be generated and stored for execution on the target system. However, again due to the memory requirements needed to store these verification SVF files, it is often not practical to store them on the non-volatile memory of the target system and verification is not performed.
One way to verify that the devices in a target system have already been programmed and, therefore, do not need to be programmed is to examine the value stored in a particular location in the device and compare it to a verifying value. For example, many devices include a User Register that can be loaded with a version number, checksum, or other verification or identification information. Whenever an associated value stored in, for example the non-volatile memory of the target system, does not match the value programmed in, for example, the User Register of the programmable device, the programmable device can be selectively reprogrammed. If the value stored in the User Register matches or otherwise correlates to the associated value stored in the non-volatile memory of the target system, the device is determined to have been programmed correctly and re-programming is avoided.
A problem with User Register or similar schemes is that the device might have been partially programmed such that the user register information has been programmed into the device, but the rest of the data was not. In this case, when the device's user register is accessed, its value will match, but the device can be non-functional.
Another problem with currently available self-programming, in-system programming or configuration technology is the time it takes to program each device. For example, in an exemplary target system using an 80C51 microcontroller running at 16 Mhz, it takes approximately 13 seconds to program an XC95144XL CPLD. It is not unusual to find four or more of these devices in a target system. With currently available in-system self-programming technology, the devices are programmed one at a time. So, if a target system includes four devices, it will take approximately 52 seconds to program four devices. This is problematic in a manufacturing environment, for example, because no device testing or other procedures can be performed while device programming or configuration is taking place. In a field environment, where re-programming is used instead of device verification, the user must wait during a boot-up period before being able to use the target system. This can be annoying is some instances, and make the target system unusable in others.
For the foregoing reasons, it has been desired to provide a method of in-system programming or configuration that has a reduce demand on target system resources, improves device programming or configuration speed and provides a method of thorough verification that does not place an undue burden on system resources.